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Abstract 
NTP format timestamps are used by several RTP protocols for 
synchronisation and statistical measurements. This memo specifies 
Session Description Protocol (SDP) signalling that identifies 
timestamp reference clock sources and SDP signalling that identifies 
the media clock sources in a multimedia session. 
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1. Introduction 


RTP protocols use NIP format timestamps to facilitate multimedia 
session synchronisation and to provide estimates of round-trip time 
(RTT) and other statistical parameters. 


Information about media clock timing exchanged in NTP format 
timestamps may come from a clock that is synchronised to a global 
time reference, but this cannot be assumed, nor is there a 
standardised mechanism available to indicate that timestamps are 
derived from a common reference clock. Therefore, RTP 
implementations typically assume that NIP timestamps are taken using 
unsynchronised clocks and must compensate for absolute time 
differences and rate differences. Without a shared reference clock, 
RTP can time align flows from the same source at a given receiver 
using relative timing; however, tight synchronisation between two or 
more different receivers (possibly with different network paths) or 
between two or more senders is not possible. 


High performance AV systems often use a reference media clock 
distributed to all devices in the system. The reference media clock 
may be distinct from the reference clock used to provide timestamps. 
A reference media clock may be provided along with an audio or video 
signal interface, or via a dedicated clock signal (e.g., genlock 
[SMPTE-318M-1999] or audio word clock [AES11-2009]). If sending and 
receiving media clocks are known to be synchronised to a common 
reference clock, performance can be improved by minimising buffering 
and avoiding rate conversion. 


This specification defines SDP signalling of timestamp reference 
clock sources and media reference clock sources. 


1.1. Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 

2. Applications 
Timestamp reference clock source and media clock signalling benefit 


applications requiring synchronised media capture or playout and low 
latency operation. 
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Examples include, but are not limited to: 


Social TV: "Inter-Destination Media Synchronization (IDMS) Using the 
RTP Control Protocol (RTCP)" [RFC7272] defines social TV as the 
combination of media content consumption by two or more users at 
different devices and locations and real-time communication 
between those users. An example of social TV is where two or more 
users are watching the same television broadcast at different 
devices and/or locations while communicating with each other using 
text, audio, and/or video. A skew in the media playout of the two 
or more users can have adverse effects on their experience. A 
well-known use case here is one friend experiencing a goal ina 
football match well before or after other friends. 


Video Walls: A video wall consists of multiple computer monitors, 
video projectors, or television sets tiled together contiguously 
or overlapped in order to form one large screen. Each of the 
screens reproduces a portion of the larger picture. In some 
implementations, each screen or projector may be individually 
connected to the network and receive its portion of the overall 
image from a network-connected video server or video scaler. 
Screens are refreshed at 50 or 60 hertz or potentially faster. If 
the refresh is not synchronised, the effect of multiple screens 
acting as one is broken. 


Networked Audio: Networked loudspeakers, amplifiers, and analogue 
input/output (I/O) devices transmitting or receiving audio signals 
via RTP can be connected to various parts of a building or campus 
network. Such situations can, for example, be found in large 
conference rooms, legislative chambers, classrooms (especially 
those supporting distance learning), and other large-scale 
environments such as stadiums. Since humans are more sensitive to 
differences in audio delay, this use case needs even more accuracy 
than the video wall use case. Depending on the exact application, 
the need for accuracy can then be in the range of microseconds 
[Olsen]. 


Sensor Arrays: Sensor arrays contain many synchronised measurement 
elements producing signals that are then combined to form an 
overall measurement. Accurate capture of the phase relationships 
between the various signals arriving at each element of the array 
is critically important for proper operation. Examples include 
towed or fixed sonar arrays, seismic arrays, and phased arrays 
used in radar applications, for instance. 
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3; 


Definitions 
The following definitions are used in this document: 
media level: Media-level information applies to a single SDP media 
stream. In an SDP description, media-level information appears 
after each "m"-line. 
multimedia session: A set of multimedia senders and receivers as 
well as the data streams flowing from senders to receivers. SDP 


[RFC4566] describes multimedia sessions. 


RTP media stream: A single stream of RTP packets identified by an 
RTP Synchronisation Source (SSRC). 


RTP sender: The device generating an associated RTP media stream. 


session level: Session-level information applies to an entire 
multimedia session. In an SDP description, session-level 
information appears before the first "m"-line. 


source level: Source-level information applies to a specific RTP 
media stream. "Source-Specific Media Attributes in the Session 
Description Protocol (SDP)" [RFC5576] defines how source-level 


information is included into an SDP session description. 


traceable time: A clock is considered to provide traceable time if 
it can be proven to be synchronised to International Atomic Time 
(TAI). Coordinated Universal Time (UTC) is a time standard 
synchronised to TAI. UTC is, therefore, also considered traceable 
time once leap seconds have been taken into account. GPS 
[IS-GPS-200F] is commonly used to provide a TAI traceable time 
reference. Some network time synchronisation protocols (e.g., 
Precision Time Protocol (PTP) [IEEE1588-2008] and NTP) can 
explicitly indicate that the master clock is providing a traceable 
time reference over the network. 


Timestamp Reference Clock Source Signalling 


The NIP format timestamps used by RTP are taken by reading a local 
real-time clock at the sender or receiver. This local clock may be 
synchronised to another clock (time source) by some means, or it may 
be unsynchronised. A variety of methods are available to synchronise 
local clocks to a reference time source, including network time 
protocols (e.g., NTP [RFC5905] and PTP [IEEE1588-2008]) and radio 
clocks (e.g., GPS [IS-GPS-200F]). 
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The following sections describe and define SDP signalling, indicating 
whether and how the local timestamping clock in an RTP sender or 
receiver is synchronised to a reference clock. 


4.1. Clock Synchronisation 


Two or more local clocks that are sufficiently synchronised will 
produce timestamps for a given RTP event that can be used as if they 
came from the same clock. Timestamps produced in one RTP sender or 
receiver can be directly compared to a local clock in another RTP 
sender or receiver. 


The accuracy of synchronisation required is application dependent. 
See "Applications" (Section 2) for a discussion of applications and 
their corresponding requirements. To serve as a reference clock, 
clocks must minimally be "syntonised" (exactly frequency matched) to 
one another. 


Sufficient synchronisation can typically be achieved by using a 
network time protocol (e.g., NTP, 802.1AS, and IEEE 1588-2008) to 
synchronise all devices to a single master clock. 


Another approach is to use clocks providing a global time reference 
(e.g., GPS, Galileo, and GLONASS). This concept may be used in 
conjunction with network time protocols as some protocols (e.g., PTP 
and NTP) allow master clocks to indicate explicitly that they are 
providing traceable time. 


4.2. Identifying NTP Reference Clocks 


A single NTP server is identified by a hostname (or IP address) and 
an optional port number. If the port number is not indicated, it is 
assumed to be the standard NTP port (123). 


Two or more NTP servers MAY be listed at the same level in the 
session description to indicate that all of the listed servers 
deliver the same reference time and may be used interchangeably. RIP 
senders and receivers are assured proper synchronisation regardless 
of which server they choose and, in support of fault tolerance, may 
switch servers while streaming. 


4.3. Identifying PTP Reference Clocks 


The Precision Time Protocol (PTP) as standardised in IEEE 1588 
provides a shared reference clock in a network. IEEE 1588 provides 
sub-microsecond synchronisation between devices on a LAN and 
typically locks within seconds at startup. With support from 
Ethernet switches, IEEE 1588 protocols can achieve nanosecond timing 
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accuracy in LANs. Network interface chips and cards supporting 
hardware timestamping of timing-critical protocol messages are also 
available. 


Three flavours of IEEE 1588 are in use today: 


Oo IEEE 1588-2002 [IEEE1588-2002]: the original "Standard for a 
Precision Clock Synchronization Protocol for Networked Measurement 
and Control Systems". This is also known as IEEE1588v1 or PTPvl. 


o IEEE 1588-2008 [IEEE1588-2008]: the second version of the 
"Standard for a Precision Clock Synchronization Protocol for 
Networked Measurement and Control Systems". This is a revised 
version of the original IEEE1588-2002 standard and is also known 
as ITEEE1588v2 or PTPv2. IEEE 1588-2008 is not protocol compatible 
with IEEE 1588-2002. 


o IEEE 802.1AS [IEEE802.1AS-2011]: "Timing and Synchronization for 
Time Sensitive Applications in Bridged Local Area Networks". This 
is a profile of IEEE 1588-2008 that is Layer 2 only and is for use 
in Audio/Video Bridged LANs as described in IEEE 802.1BA-2011 
[IEEE802.1BA-2011]. 


Each IEEE 1588 clock is identified by a 64-bit Extended Unique 
Identifier (EUI-64) called a "ClockIdentity". A slave clock using 
one of the IEEE 1588 family of network time protocols acquires the 
ClockIdentity of the grandmaster clock that is the ultimate source of 
timing information for the network. A boundary clock, which is 
itself slaved to another boundary clock, or the grandmaster passes 
the grandmaster ClockIdentity through to its slaves. 


Several instances of the IEEE 1588 protocol may operate independently 
on a single network, forming distinct PTP domains, each of which may 
have a different grandmaster clock. As the IEEE 1588 standards have 
evolved, the definition of PTP domains has changed. IEEE 1588-2002 
identifies protocol subdomains by a textual name, but IEEE 1588-2008 
identifies protocol domains using a numeric domain number. 802.1AS is 
a Layer 2 profile of IEEE 1588-2008 supporting a single numeric clock 
domain (0). 


When PTP domains are signalled via SDP, senders and receivers SHOULD 
check that both grandmaster ClockIdentity and the PTP domain match 
when determining clock equivalence. 


Two or more IEEE 1588 clocks MAY be listed at the same level in the 
session description to indicate that all of the listed clocks are 
candidate grandmaster clocks for the domain or deliver the same 
reference time and may be used interchangeably. RTP senders and 
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receivers are assured proper synchronisation regardless of which 
synchronisation source they choose and, in support of fault 
tolerance, may switch the reference clock source while streaming. 


The PTP protocols employ a distributed election protocol called the 
"Best Master Clock Algorithm" (BMCA) to determine the active clock 
master. The clock master choices available to BMCA can be restricted 
or biased by configuration parameters to influence the election 
process. In some systems, it may be desirable to limit the number of 
possible PTP clock masters to avoid the need to re-signal timestamp 
reference clock sources when the clock master changes. 


4.4. Identifying Global Reference Clocks 


Global reference clocks provide a source of traceable time, typically 
via a hardware radio receiver interface. Examples include GPS, 
Galileo, and GLONASS. Apart from the name of the reference clock 
system, no further identification is required. 


4.5. Private Reference Clocks 


In other systems, all RTP senders and receivers may use a timestamp 
reference clock that is not provided by one of the methods listed 
above. Examples may include the reference time information provided 
by digital television or cellular services. These sources are 
identified as "private" reference clocks. All RTP senders and 
receivers in a session using a private reference clock are assumed to 
have a mechanism outside this specification for determining whether 
their timestamp reference clocks are equivalent. 


4.6. Local Reference Clocks 


[RFC3550] allows senders and receivers to either use a local 
wallclock reference for their NTP timestamps or, by setting the 
timestamp field to 0, supply no timestamps at all. Both are common 
practice in embedded RTP implementations. These clocks are 
identified as "local" and can, at best, be assumed to be equivalent 
to clocks originating from the same device. 


4.7. Traceable Reference Clocks 


A timestamp reference clock source may be labelled "traceable" if it 
is known to be delivering traceable time, provided adjustments are 
made for differing epochs, timezones, and leap seconds. Timestamps 
taken using clocks synchronised to a traceable time source can be 
directly compared even if the clocks are synchronised to different 
sources or via different mechanisms. 
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Marking a clock as traceable allows additional information (e.g., IP 
addresses, PTP master identifiers, and the like) to be omitted from 
the SDP since any traceable clock available at the answerer is 
considered to be an appropriate timestamp reference clock. For 
example, an offerer could specify ts-refclk:ntp=/traceable/ and the 
answerer could use GPS as a reference clock since GPS is a source of 
traceable time. 


4.8. SDP Signalling of Timestamp Reference Clock Source 


Specification of the timestamp reference clock source may be at any 
or all levels (session, media, or source) of an SDP description (see 
level definitions in Section 3 earlier in this document for more 
information). 


Timestamp reference clock source signalling included at the session 
level provides default parameters for all RTP sessions and sources in 
the session description. More specific signalling included at the 
media level overrides session-level signalling. More specific 
signalling included at the source level overrides media-level 
signalling. 


If timestamp reference clock source signalling is included anywhere 
in an SDP description, it must be properly defined for all levels in 
the description. This may simply be achieved by providing default 
Signalling at the session level. 


Timestamp reference clock parameters may be repeated at a given level 
(i.e., for a session or source) to provide information about 
additional servers or clock sources. If the attribute is repeated at 
a given level, all clocks described at that level are assumed to be 
equivalent. Traceable time sources MUST NOT be mixed with non- 
traceable time sources at any given level. 


Note that clock source parameters may change from time to time, for 
example, as a result of a PTP grandmaster election. SIP [RFC3261] 
supports the re-signalling of updated SDP information; however, other 
protocols may require additional notification mechanisms. 


General forms of usage: 


session level: a=ts-refclk:<clksrc> 
media level: a=ts-refclk:<clksrc> 
source level: a=ssrce:<ssrc-id> ts-refclk:<clksrc> 
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ABNF [RFC5234] grammar for the timestamp reference clock attribute: 


; external references: 


POS-DIGIT = <See 
token = <See 
byte-string = <See 
DIGIT = <See 
HEXDIG = <See 
CRLF = <See 
hostport = <See 


timestamp-refclk = 


clksre 


= ntp / ptp 


clksrc-ex 


clksrc-ext 
clksrc-param-name 
clksrc-param-value 


ntp 


ntp-server-addr = 


ptp 


ptp-version 


ptp-version-ext 
ptp-server 


ptp-gmid 


I|_“wN™ Il 


ptp-domain = 


; PTP domain allowed characters: 0x21-0x7E (IEEE 1588-2002) 


RFC 
RFC 
RFC 
RFC 
RFC 
RFC 
RFC 


4566> 
4566> 
4566> 
5234> 
5234> 
5234> 
3261, 


with revisions from RFC 5954> 


"ts-refclk:" clksrc CRLF 


/ gps / gal / glonass / local / private / 


t 


to 


ken 


clksrc-param-name clksrc-param-value 


= ["="_byte-string ] 


"ntp="_ ntp-server-addr 
hostport / "/traceable/" 


"ptp="_ ptp-version ":" ptp-server 
"TEEE1588-2002" 

"TEEE1588-2008" 
"TEEE802.1AS-2011" 
ptp-version-ext 


token 


ptp-gmid 
"traceable" 


EUI64 


[":" ptp-domain] 


ptp-domain-name / ptp-domain-nmbr 


ptp-domain-name = "domain-name=" 1*16ptp-domain-char 
ptp-domain-char = 


Sx21- 


7E 


; PTP domain allowed number range: 0-127 (IEEE 1588-2008) 


ptp-domain-nmbr 


ptp-domain-dgts = 


ptp-domain-nl 


ptp-domain-n2 = 
ptp-domain-n3 = 


gps 


Williams, 


= " gps " 


et al. 


= "domain-nmbr=" ptp-domain-dgts 


ptp-domain-n1 / ptp-domain-n2 / ptp-domain-n3 


DIGIT 7 0-9 
POS-DIGIT DIGIT ; 10-99 
("10"/"11") DIGIT ; 100-119 
"12" %x30-37 ; 120-127 


Standards Track 
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gal = "gal" 

glonass = "glonass" 

local = "local" 

private = "private" [ ":traceable" ] 
EUI64 = 7(2HEXDIG "-") 2HEXDIG 


Figure 1: Timestamp Reference Clock Source Signalling 
4.8.1. Examples 


Figure 2 shows an example SDP description with a timestamp reference 
clock source defined at the session level. 


v=0 

o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 
s=SDP Seminar 

i=A Seminar on the session description protocol 
u=http://www.example.com/seminars/sdp.pdf 
e=j.doe@example.com (Jane Doe) 

c=IN IP4 233.252.0.1/64 

t=2873397496 2873404696 

a=recvonly 

a=ts-refclk:ntp=/traceable/ 

m=audio 49170 RTP/AVP 0 

m=video 51372 RTP/AVP 99 

a=rtpmap:99 h263-1998/90000 


Figure 2: Timestamp Reference Clock Definition at the Session Level 
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Figure 3 shows an example SDP description with timestamp reference 
clock definitions at the media level overriding the session-level 
defaults. 


v=0 

o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 
s=SDP Seminar 

i=A Seminar on the session description protocol 
u=http://www.example.com/seminars/sdp.pdf 
e=j.doe@example.com (Jane Doe) 

c=IN IP4 233.252.0.1/64 

t=2873397496 2873404696 

a=recvonly 

a=ts-refclk:local 

m=audio 49170 RTP/AVP 0 
a=ts-refclk:ntp=203.0.113.10 
a=ts-refclk:ntp=198.51.100.22 

m=video 51372 RTP/AVP 99 

a=rtpmap:99 h263-1998/90000 
a=ts-refclk:ptp=IEEE802.1AS—-2011:39-A7-94-FF-FE-07-CB-DO 


Figure 3: Timestamp Reference Clock Definition at the Media Level 


Figure 4 shows an example SDP description with a timestamp reference 
clock definition at the source level overriding the session-level 
default. 


v=0 

o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 
s=SDP Seminar 

i=A Seminar on the session description protocol 
u=http://www.example.com/seminars/sdp.pdf 
e=j.doe@example.com (Jane Doe) 

c=IN IP4 233.252.0.1/64 

t=2873397496 2873404696 

a=recvonly 

a=ts-refclk:local 

m=audio 49170 RTP/AVP 0 

m=video 51372 RTP/AVP 99 

a=rtpmap:99 h263-1998/90000 

a=ssrc:12345 ts-refclk:ptp=IEEE802.1AS—2011:39-A7-94-FF-FE-07-CB-DO 


Figure 4: Timestamp Reference Clock Signalling at the Source Level 
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5. 


5y 


5 


Media Clock Source Signalling 


The media clock source for a stream determines the timebase used to 
advance the RTP timestamps included in RTP packets. The media clock 
may be asynchronously generated by the sender, it may be generated in 
fixed relationship to the reference clock, or it may be generated 
with respect to another stream on the network (which is presumably 
being received by the sender). 


1. Asynchronously Generated Media Clock 


In the simplest sender implementation, the sender generates media by 
sampling audio or video according to a free-running local clock. The 
RTP timestamps in media packets are advanced according to this media 
clock, and packet transmission is typically timed to regular 
intervals on this timeline. The sender may or may not include an NTP 
timestamp in sender reports to allow mapping of this asynchronous 
media clock to a reference clock. 


The asynchronously generated media clock is the assumed mode of 
operation when there is no signalling of the media clock source. 
Alternatively, an asynchronous media clock may be explicitly 
signalled. 


a=mediaclk:sender 


-2. Direct—-Referenced Media Clock 


A media clock may be directly derived from a reference clock. For 
this case, it is required that a reference clock be specified with an 
a=ts-refclk attribute (Section 4.8). 


The signalling optionally indicates a media clock offset value. The 
offset indicates the RTP timestamp value at the epoch (time of 
origin) of the reference clock. To use the offset, implementations 
need to compute RIP timestamps from reference clocks. To simplify 
these calculations, streams utilizing offset signalling SHOULD use a 
TAI timestamp reference clock to avoid complications introduced by 
leap seconds. See [RFC7164] for further discussion of leap-second 
issues in timestamp reference clocks. 


To compute the RTP timestamp against an IEEE 1588 (TAI-based) 
reference, the time elapsed between the 00:00:00 1 January 1970 IEEE 
1588 epoch and the current time must be computed. Between the epoch 
and 1 January 2013, there were 15,706 days (including extra days 
during leap years). Since there are no leap seconds in a TAI 
reference, there are exactly 86,400 seconds during each of these days 
or a total of 1,356,998,400 seconds from the epoch to 00:00:00 1 
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January 2013. A 90 kHz RTP clock for a video stream would have 
advanced 122,129,856,000,000 units over this period. With a 
signalled offset of 0, the RTP clock value modulo the 32-bit unsigned 
RTP timestamp representation in the RTP header would have been 
2,460,938,240 at 00:00:00 1 January 2013. If an offset of 23,465 had 
been signalled, the clock value would have been 2,460,961,705. 


In order to use an NTP reference, the actual time elapsed between the 
00:00:00 1 January 1900 NTP epoch to the current time must be 
computed. 2,208,988,800 seconds elapsed between the NTP epoch and 
00:00:00 1 January 1970 [RFC0868]. Between the beginning of 1970 and 
2013, there were 15,706 days elapsed (including extra days during 
leap years) and 25 leap seconds inserted. There is, therefore, a 
total of 3,565,987,225 seconds from the NTP epoch to 00:00:00 1 
January 2013. A 90 kHz RTP clock for a video stream would have 
advanced 320, 938,850,250,000 units over this period. With a 
signalled offset of 0, the RTP clock value modulo the 32-bit unsigned 
representation would have been 1,714,023,696 at 00:00:00 1 January 
2013. 


If no offset is signalled, the offset can be inferred at the receiver 
by examining RTCP sender reports that contain NTP and RTP timestamps, 
which combined define a mapping. The NTP/RTP timestamp mapping 
provided by RTCP sender reports (SRs) takes precedence over that 
signalled through SDP; however, the media clock rate implied by the 
SRs MUST be consistent with the rate signalled. 


A rate modifier may be specified. The modifier is expressed as the 
ratio of two integers and modifies the rate specified or implied by 
the media description by this ratio. If omitted, the rate is assumed 
to be the exact rate specified or implied by the media format. For 
example, without a rate specification, the RTP clock for an 8 kHz 
G.711 audio stream will advance exactly 8000 units for each second 
advance in the reference clock from which it is derived. 


The rate modifier is primarily useful for accommodating certain 
"oddball" audio sample rates associated with NTSC video (see 

Figure 7). Modified rates are not advised for video streams that 
generally use a 90 kHz RTP clock regardless of frame rate or sample 
rate used for embedded audio. 


a=mediaclk:direct [=<offset>] [rate=<rate numerator>/<rate 
denominator>] 
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5.3. Stream-Referenced Media Clock 


A common synchronisation architecture for audio/visual systems 
involves distributing a reference media clock from a master device to 
a number of slave devices, typically by means of a cable. Examples 
include audio word clock distribution and video black burst 
distribution. In this case, the media clock is locally generated, 
often by a crystal oscillator, and is not locked to a timestamp 
reference clock. 


To support this architecture across a network, a master clock 
identifier is associated with an RTP media stream carrying media 
clock timing information from a master device. The master clock 
identifier represents a media clock source in the master device. 
Slave devices in turn associate the master media clock identifier 
with streams they transmit, signalling the synchronisation 
relationship between the master and the transmitter’s media clock. 


Slave devices recover media clock timing from the clock master 
stream, using it to synchronise the slave’s media clock with the 
master. If a common reference clock is available, NTP timestamps in 
the master clock RIP media stream are taken using the shared 
reference clock. The NTP timestamps communicate information about 
media clock timing (rate and phase) from the master to the slave 
devices. NTP timestamps are communicated in the usual RTP fashion 
via RTCP SRs, or via the [RFC6051] header extension. If no shared 
reference clock is available or signalled, a slave can synchronise to 
the master’s media clock using RTP timestamps alone as described in 
Section 5.1 of [RFC3550]. 


Note that the slaving of a device media clock to a master device does 
not affect RTP inter-media synchronisation. Time-aligned playout of 
two or more RTP sources still relies upon NTP timestamps supplied via 
RTCP SRs or by the RFC 6051 timestamp header extension. 


In a given system, master clock identifiers must uniquely identify a 
single media clock source. Such identifiers MAY be manually 
configured; however, identifiers SHOULD be generated according to the 
"short-term persistent RTCP CNAME" algorithm as described in 
[RFC7022]. Master clock identifiers not already in base64 format 
MUST be encoded as base64 strings when used in SDP. Although the 
CNAME algorithm is used to generate the master clock identifier, it 
is used to tag RTP sources in SDP descriptions and does not appear in 
RTCP as a CNAME. 


A reference stream can be an RTP stream or an Audio Video Bridging 
(AVB) stream based on the [IEEE1722] standard. 
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An RTP clock master stream SHOULD be identified at the source level 
by an SSRC [RFC5576] and master clock identifier. An RTP stream that 
provides media clock timing directly from a reference media clock 
(e.g., internal crystal, audio word clock, or video black burst 
signal) SHOULD tag the stream as a master clock source using the 
"src:" prefix. If master clock identifiers are declared at the media 
or session level, all RTP sources at or below the level of 
declaration MUST provide equivalent timing to a slave receiver. 


a=ssrc:<ssrc> mediaclk:id=src:<media-clktag> sender 
a=mediaclk:id=srce:<media-clktag> sender 


A transmitted RTP stream slaved to the media clock master is 
signalled by including a master clock identifier: 


a=mediaclk:id=<media-clktag> sender 


An RTP media sender indicates that it is slaved to an IEEE 1722 clock 
master via a stream identifier (an EUI-64): 


a=mediaclk: IEEE1722=<StreamID> 
An RTP media sender may gateway IEEE 1722 media clock timing to RTP: 
a=mediaclk:id=srce:<media-clktag> IEEE1722=<StreamID> 
5.4. SDP Signalling of Media Clock Source 


Specification of the media clock source may be at any or all levels 
(session, media, or source) of an SDP description (see level 
definitions (Section 3) earlier in this document for more 
information). 


Media clock source signalling included at session level provides 
default parameters for all RTP sessions and sources in the session 
description. More specific signalling included at the media level 
overrides session-level signalling. Further, source-level signalling 
overrides media clock source signalling at the enclosing media level 
and session level. 


Media clock source signalling may be present or absent on a per- 
stream basis. In the absence of media clock source signals, 
receivers assume an asynchronous media clock generated by the sender. 


Media clock source parameters may be repeated at a given level (i.e., 


for a session or source) to provide information about additional 
clock sources. If the attribute is repeated at a given level, all 
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clocks described at that level are comparable clock sources and may 
be used interchangeably. 


General forms of usage: 


session level: a=mediaclk:<mediaclock> 
media level: a=mediaclk:<mediaclock> 
source level: a=ssrc:<ssrc-id> mediaclk:<mediaclock> 


ABNF [RFC5234] grammar for the media clock reference attribute: 


; external references: 


integer = <See RFC 4566> 

token = <See RFC 4566> 

byte-string = <See RFC 4566> 

base64 = <See RFC 4566> 

SP = <See RFC 5234> 

DIGIT = <See RFC 5234> 

HEXDIG = <See RFC 5234> 

media-clksrce = "mediaclk:" [media-clkid SP] mediaclock 
media-clkid = "id=" [ "src:" ] media-clktag 


media-clktag = base64 


mediaclock = sender / direct / ieeel722-streamid / mediaclock-ext 
mediaclock-ext = mediaclock-param-name mediaclock-param-value 
mediaclock-param-name = token 

mediaclock-param-value = [ "=" byte-string ] 

sender = "sender" 

direct = "direct" [ "=" 1*DIGIT ] [SP rate] 

rate = "rate=" integer "/" integer 


ieeel722-streamid "TEEE1722="" avb-stream-id 
avb-stream-id EUI64 
EUI64 = 7(2HEXDIG "-") 2HEXDIG 


Figure 5: Media Clock Source Signalling 
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5.5. Examples 


Figure 6 shows an example SDP description -- 8 channels of 24-bit, 48 
kHz audio transmitted as a multicast stream. Media clock is derived 
directly from an IEEE 1588-2008 reference. 


v=0 

o=- 1311738121 1311738121 IN IP4 192.0.2.1 

c=IN IP4 233.252.0.1/64 

s= 

t=0 0 

m=audio 5004 RTP/AVP 96 

a=rtpmap:96 L24/48000/8 

a=sendonly 
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 
a=mediaclk:direct=963214424 


Figure 6: Media Clock Directly Referenced to IEEE 1588-2008 


Figure 7 shows an example SDP description -- 2 channels of 24-bit, 
44056 kHz NTSC "pull-down" media clock derived directly from an IEEE 
1588-2008 reference clock. 


v=0 

o=- 1311738121 1311738121 IN IP4 192.0.2.1 

c=IN IP4 233.252.0.1/64 

s= 

t=0 0 

m=audio 5004 RTP/AVP 96 

a=rtpmap:96 L24/44100/2 

a=sendonly 
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 
a=mediaclk:direct=963214424 rate=1000/1001 


Figure 7: "Oddball" Sample Rate Directly Referenced to IEEE 1588-2008 
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Figure 8 shows the same 48 kHz audio transmission from Figure 6 with 
media clock derived from another RTP stream. 


v=0 

o=- 1311738121 1311738121 IN IP4 192.0.2.1 

c=IN IP4 233.252.0.1/64 

s= 

t=0 0 

m=audio 5004 RTP/AVP 96 

a=rtpmap:96 L24/48000/2 

a=sendonly 
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 
a=mediaclk:id=MDA6NjJA6MmI 6MjJA6MTI6MWY= sender 


Figure 8: RTP Stream with Media Clock Slaved to a Master 


Figure 9 shows the same 48 kHz audio transmission from Figure 6 with 
media clock derived from an IEEE 1722 AVB stream. 


v=0 

o=- 1311738121 1311738121 IN IP4 192.0.2.1 

c=IN IP4 233.252.0.1/64 

s= 

t=0 0 

m=audio 5004 RTP/AVP 96 

a=rtpmap:96 L24/48000/2 

a=sendonly 
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 
a=mediaclk: IEEE1722=38-D6—-6D-8E-D2-78-13-2F 


Figure 9: RTP Stream with Media Clock Slaved to an 
IEEE 1722 Master Device 


6. Signalling Considerations 


Signalling of timestamp reference clock source (Section 4.8) and 
media clock source (Section 5.4) is defined to be used either by 
applications that implement the SDP Offer/Answer model [RFC3264] or 
by applications that use SDP to describe media and transport 
configurations. 


A description SHOULD include both reference clock signalling and 


media clock signalling. If no reference clock is available, this 
SHOULD be signalled as a local reference (Section 4.6). 
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When no media clock signalling is present, an asynchronous media 
clock (Section 5.1) MUST be assumed. When no reference clock 
signalling is present, a local reference clock (Section 4.6) MUST be 
assumed. 


If a reference clock is not signalled or a local reference is 
specified, the corresponding media clock may be established as rate 
synchronised with no assurance of time synchronisation. 


When the description signals a direct-referenced media clock 
(Section 5.2), reference clock signalling is REQUIRED. Asynchronous 
and stream-referenced media clocks (Section 5.3) MAY be specified 
with or without a reference clock signalling. 


6.1. Usage in Offer/Answer 


During offer/answer, clock source signalling via SDP uses a 
declarative model. Supported media and/or reference clocks are 
specified in the offered SDP description. The answerer may accept or 
reject the offer in an application-specific way depending on the 
clocks that are available and the clocks that are offered. For 
example, an answerer may choose to accept an offer that lacks a 
common clock by falling back to a lower-performance mode of operation 
(e.g., by assuming reference or media clocks are local rather than 
shared). Conversely, the answerer may choose to reject the offer 
when the offered clock specifications indicate that the available 
reference and/or media clocks are incompatible. 


While negotiation of reference clock and media clock attributes is 
not defined in this document, negotiation MAY be accomplished using 
the capabilities negotiation procedures defined in [RFC5939]. 


6.1.1. Indicating Support for Clock Source Signalling 


An offerer or answerer indicates support for media clock signalling 
by including a reference or media clock specification in the SDP 
description. An offerer or answerer without specific reference or 
media clocks to signal SHOULD indicate support for clock source 
Signalling by including a local reference clock (Section 4.6) 
specification in the SDP description. 


6.1.2. Timestamp Reference Clock 


If one or more of the reference clocks specified in the offer are 
usable by the answerer, the answerer SHOULD respond with an answer 
containing the subset of reference clock specifications in the offer 
that are usable by the answerer. If the answerer rejects the offer 
because the available reference clocks are incompatible, the 
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rejection MUST contain at least one timestamp reference clock 
specification usable by the answerer so that appropriate information 
is available for diagnostics. If no external reference clock is 
available to the answerer, a local reference clock (Section 4.6) 
specification SHOULD be included in the rejection. 


In both offers and answers, multiple reference clock specifications 
indicate equivalent clocks from different sources that may be used 
interchangeably. RTP senders and receivers are assured proper 
synchronisation regardless of which of the specified sources is 
chosen and, in support of fault tolerance, may switch clock sources 
while streaming. 


6.1.3. Media Clock 


If the media clock mode specified in the offer is acceptable to the 
answerer, the answerer SHOULD respond with an answer containing the 
same media clock specification as the offer. If the answerer rejects 
the offer because the available reference clocks are incompatible, 
the rejection MUST contain a media clock specification supported by 
the answerer so that appropriate information is available for 
diagnostics. If no shared media clocks are available to the 
answerer, an asynchronous media clock (Section 5.1) specification 
SHOULD be included in the rejection. 


6.2. Usage Outside of Offer/Answer 


SDP can be employed outside of the offer/answer context, for 
instance, for multimedia sessions that are announced through the 
Session Announcement Protocol (SAP) [RFC2974] or streamed through the 
Real Time Streaming Protocol (RTSP) [RFC2326]. 


Devices using published descriptions to join sessions SHOULD assess 
their synchronisation compatibility with the described session based 
on the clock source signalling and SHOULD NOT attempt to joina 
session with incompatible reference or media clocks. 


7. Security Considerations 


Entities receiving and acting upon an SDP message should note that a 
session description cannot be trusted unless it has been obtained by 
an authenticated transport protocol from a known and trusted source. 
Many different transport protocols may be used to distribute a 
session description, and the nature of the authentication will differ 
from transport to transport. For some transports, security features 
are often not deployed. In case a session description has not been 
obtained in a trusted manner, the endpoint should exercise care 
because, among other attacks, the media sessions received may not be 


Williams, et al. Standards Track [Page 21] 


RFC 7273 RTP Clock Source Signalling June 2014 


the intended ones, the destination where media is sent to may not be 
the expected one, and any of the parameters of the session may be 
incorrect. 


Incorrect reference or media clock parameters may cause devices or 
streams to synchronise to unintended clock sources. Normally, this 
simply results in failure to establish a session or failure to 
synchronise once connected. Enough devices fraudulently assigned to 
a specific clock source (e.g., a particular IEEE 1588 grandmaster) 
may, however, constitute a successful denial-of-service attack on 
that source. Devices MAY wish to validate the integrity of the clock 
description through some means before connecting to unfamiliar clock 
sources. 


The timestamp reference clocks negotiated by this protocol are used 
to provide media timing information to RTP. Negotiated timestamp 
reference clocks should not be relied upon to provide a secure time 
reference for security critical operations (e.g., the expiration of 
public key certificates). 


8. IANA Considerations 


This document defines two new SDP attributes: "ts-refclk" and 
"mediaclk", within the existing Internet Assigned Numbers Authority 
(IANA) registry of SDP Parameters. 


This document also defines a new IANA registry subordinate to the 
IANA SDP Parameters registry: the Media Clock Source Parameters 
registry. Within this new registry, this document defines an initial 
set of three media clock source parameters. Further, this document 
defines a second new IANA registry subordinate to the IANA SDP 
Parameters registry: the Timestamp Reference Clock Source Parameters 
registry. Within this new registry, this document defines an initial 
six parameters. 
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8.1. Reference Clock SDP Parameter 


The SDP attribute "ts-refclk" defined by this document is registered 
with the IANA registry of SDP Parameters as follows: 


SDP Attributes ( "“att-field (both session and media level)" & 
"att-field (source level)" ): 


Attribute name: ts-refclk 
Long form: Timestamp reference clock source 
Type of name: att-field 
Type of attribute: Session, media, and source level 


Subject to charset: No 


Purpose: See Section 4 of this document 
Reference: This document 
Values: See Section 8.3 of this document 


Figure 10: Reference Clock SDP Parameter IANA Registration 
The attribute has an extensible parameter field; therefore, a 


registry for these parameters is required. This new registry is 
defined in Section 8.3. 
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8.2. Media Clock SDP Parameter 


The SDP attribute "mediaclk" defined by this document is registered 
with the IANA registry of SDP Parameters as follows: 


SDP Attributes ( "“att-field (both session and media level)" & 


Attribute 


Long form: 


"att-field (source level)" ): 
name: mediaclk 


Media clock source 


Type of name: att-field 


Type of attribute: Session, media, and source level 


Subject to charset: No 


Purpose: 
Reference: 


Values: 


See Section 5 of this document 


This document 


See Section 8.4 of this document 


Figure 11: Media Clock SDP Parameter IANA Registration 


The attribute has an extensible parameter field; therefore, a 
registry for these parameters is required. The new registry is 
defined in Section 8.4. 


8.3. Timestamp Reference Clock Source Parameters Registry 


This document creates a new IANA subregistry called the Timestamp 
Reference Clock Source Parameters registry, subordinate to the IANA 
SDP Parameters registry. Each entry in the Timestamp Reference Clock 
Source Parameters registry contains: 


Name: 
Long name: 


Reference: 


Token used in the SDP description (clksrc-—param-name) 
Descriptive name for the timestamp reference clock source 
Reference to the document describing the 


SDP token (clksrc-param-name) and syntax for the optional 
value associated with the token (mediaclock-param-value) 
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Timestamp Reference Clock Source Parameters 
w. 


to be made through the Specification Required 
Name field in the table corresponds to a new 
clksrc-param-name. The Reference must specify 
to clksrc-param-value. 


+--------- tae a as ee ee eS to- 5-5 + 
| Name | Long Name | Reference 

+--------- $e Saas a a pe ee ee toa 55 S + 
| ntp | Network Time Protocol | This document, Section 4 | 
| | | | 
| ptp | Precision Time Protocol | This document, Section 4 | 
| | | | 
| gps | Global Positioning System | This document, Section 4 | 
| gal | Galileo | This document, Section 4 | 
| | | | 
| glonass | Global Navigation Satellite | This document, Section 4 | 
| | System | | 
| local | Local Clock | This document, Section 4 | 
| | | | 
| private | Private Clock | This document, Section 4 | 
E toa A A a A E ccm a + 


8.4. Media Clock Source P 


This document creates a 
Source Parameters regis 
registry. Each entry i 


contains: 
Name: Token used 
Long name: Descriptive 


Reference: Reference t 
(mediaclock 
value assoc 


arameters Registry 

new IANA subregistry called the Media Clock 
try, subordinate to the IANA SDP Parameters 

n the Media Clock Source Parameters registry 
in the SDP description (mediaclock-param-name) 
name for the media clock source type 

o the document describing the SDP token 


—-param-name) and syntax for the optional 
iated with the token (mediaclock-param-value) 


Initial values for the Media Clock Source Parameters registry are 


given below. 
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Future assignments are to be made through the Specification Required 
policy [RFC5226]. The Name field in the table corresponds to a new 
value corresponding to mediaclock-param-name. The Reference must 
specify a syntax corresponding to mediaclock-param-value. 


to-- 5-7-7 Se Se Sa en ee sc ane aa tae + 
| Name | Long Name | Reference 

a a U PaE eC ee eee ta + 

sender Asynchronously Generated This document, Section 5 

| | Media Clock | | 
| direct | Direct-Referenced Media | This document, Section 5 | 
| | Clock | | 
| IEEE1722 | IEEE1722 Media Stream | This document, Section 5 | 
| | Identifier | | 
D EEE tee gS SSS SSS ees E eS Bea ala ale at + 


8.5. Source-Level Attributes 


[RFC5576] requires new source-level attributes to be registered with 
the IANA registry named "att-field (source level)". 


8.5.1. Source-Level Timestamp Reference Clock Attribute 
The source-level SDP attribute "ts-refclk" defined by this document 
is registered with the "att-field (source level)" IANA registry of 
SDP Parameters, according to Figure 10. 

8.5.2. Source-Level Media Clock Attribute 
The source-level SDP attribute "mediaclk" defined by this document is 
registered with the "att-field (source level)" IANA registry of SDP 
Parameters, according to Figure 11. 
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